\chapter{Modélisation des données}
Avant de pouvoir construire la base de données en SQL, nous avons au préalable réalisé un modèle Entité-Association afin de de faciliter l'implantation de la base de données.


\section{Définition des Entités}
Pour commencer nous avons défini les entités à prendre en compte avec leurs attributs. 

Une entité est une population d'individus homogènes. Un attribut est une caractéristique que possède une entité. Ils  nous été demandé de créer une version ``finale'' de notre modèle. Malheureusement durant l'implentation, nous nous sommes rendus compte que certaines modifications étaient nécessaires ou plus judicieuses. C'est pourquoi, dans cette section, nous expliquerons nos choix initiaux.\\

\begin{itemize}
\item $Association$: elle est définie par le nom de l'association $nom\_assoc$, un $objectif$.\\
\item $Source$ de financement: elle finance une ou plusieurs $associations$. Le $montant$ de ce financement dépend donc de la $source$ mais aussi de l'$association$.\\
\item $Personne$: elle est soit $adherente$ soit considérée comme extérieur. Elle est uniquement définit par un $nom$ et un $prenom$. Il est aussi possible de lui rajouter d'autres attributs (non demandés dans le sujet) comme un numero de téléphone ou autres...\\
\item $Adherent$: Un $adherent$ est une personne ayant cotisé à au moins une $association$. Il faut donc préciser le prix de cette $cotisation$ qui dépend de l'$association'$. Il est définit par une adresse $mail$, une $filiere$, son $annee$ de promotion, un $login$ et un mot de passe $mdp$. IL est vrai que les $login$ peuvent être déduit du $nom$ et $prénom$ de l'adhérent. Cependant, il existe parfois certaines exceptions c'est pourquoi, nous avons préféré le rajouter en attibut.\\
\item $Bureau$: Il gère une unique association. Il est constitué d'$adhérents$ de l'$association$ en question. Ces personnes possèdent un statut dans le bureau. Pour qu'un bureau existe, il faut qu'il soit gérer par au moins un adhérent. Quant aux adhérents, ils peuvent appartenir à plusieurs bureaux en même temps et donc avoir plusieurs $statuts$. 
\item $News$ : elle permet la communication entre une $association$ et ses $adherents$. Elle est définit par son $titre$ et son $contenu$. Elle peut être commentée à plusieurs reprises par les adhérents de l'association. Seuls les membres du $bureau$ peuvent créer des $news$.\\
\item $Evenement$: il est organisé par une ou plusieurs associations. Une association peut bien sûre organiser plusieurs évènements.
Il est définit par un $nom$, une $description$, la $date$ où il a été créé, son $cout$, le $nombre de places$ total, le $lieu$, la $frequence$. Les personnes peuvent participer à l'évènement soit en tant qu'$adherent$ de l'$association$ qui organise soit en tant qu'extérieur. Le tarif n'est alors pas le même. De plus, les participants peuvent donner une $note$ à chauqe évènement. Sinon, les $adherents$ peuvent décider d'aider à l'organisation  d'un ou plusieurs $evenements$. \\
\item $Dates$: Etant donné qu'un évènement peut avoir lieu plusieurs fois dans l'année, nous avons définit cette entité afin qu'un évènement puisse avoir plusieurs dates. Grâce à cela, nous pouvons aussi avoir un historique des années précédentes. Elle est constituée d'une $date et heure de debut$ et d'une $date et heure de fin$ (qui peut ne pas être définit si l'évènement ne dure pas longtemps).  
\end{itemize}

\section{Modèle Entité-Association}
Après avoir définit chaque entité, nous avons pu créer le modèle Entité-Association ci-dessous.\\
\vspace{1cm}
\includegraphics[width=15cm]{diag.png}


 Chaque entité doit être identifiable d emanière unique. C'est pourquoi chaque entité doit posséder une $cle primaire$. Dans notre projet, il s'agit d'un $identifiant$ unique que l'on incrémente à chaque ajout d'un individu. Nous avons trouvé plus judicieux d'utiliser des numéros afin de pouvoir maniupler, par la suite, plus facilement les individus de notre de base. \\

De plus, une entité peut ne posséder uniquement qu'une clé primaire comme attribut ce qui est le cas de $Bureau$. Certaines entités sont associées plusieurs fois comme $Evenement$ et $Adherent$ par $Particip\_adherent$ et $Aider$. \\

\section{Modification apportée}
Nous avons cependant effectué quelques petites modifications. Nous avons trouvé que notre modèle comportait certaines ambiguités. En effet, une association est géré par un bureau et non plusieurs. Le problème est que si nous changions la cardinalité 1,n en 1,1 nous étions obligés d'effectuer une normalisation et de faire disparaitre l'entité $Bureau$. Cependant, seuls les membres du bureau peuvent créer des news, et non tous les adhérents. NOus voulions vraiment pouvoir différencier ces deux cas et donc conserver l'entité bureau. Nous avons donc décidé d'ajouter l'attribut $année\_bureau$. Ainsi, une association peut désormais avoir l'historique de ses $bureaux$.

De plus, nous n'arrivions pas à ce qu'un $adherent$ puisse poster plusieurs commentaires sur une même $news$. En effet, une fois la transformation en modèle relationnel faite, $commentaire$ (à l'origine $commenter$ dans notre modèle Entité-Association) à pour clé primaire les deux clés étrangères $id\_adherent$ et $id\_news$. \\
\vspace{1cm}


\noindent COMMENTAIRE (\underline{$\sharp$id\_news}, \underline{$\sharp$id\_adherent})\\
NEWS (\underline{id\_news}, titre, contenu)\\
ADHERENT (\underline{id\_adherent}, mail, filière, année, login, mdp, $\sharp$id\_personne)\\


Ce doublon ne peut donc être créé qu'une seule fois puisqu'en tant que clé primaire il doit être unique. Nous avons ajouter une entité $Commentaire$ à notre modèle Entité-Association définit par $id\_commentaire$. Par conséquent, cela peut nous permettre par la suite d'ajouter d'autres attributs comme le contenu des commentaires ou la date d'envoi.\\
\vspace{1cm}


\noindent COMMENTAIRE (\underline{id\_commentaire}, $\sharp$id\_news, $\sharp$id\_adherent)\\
NEWS (\underline{id\_news}, titre, contenu)\\
ADHERENT (\underline{id\_adherent}, mail, filière, année, login, mdp)\\

Ensuite, il est possible qu'une personne soit $adherente$ d'une association mais qu'elle n'ait pas encore payé sa cotisation. Nous avons donc voulu obtenir cette information en ajoutant un booléen $paye$ partagé par $adherent$ et $association$. Nous avons alors déplacé le prix de la $cotisation$ dans $association$.\\

Finalement, nous avons obtenus ce schéma:\\\vspace{1cm}

\includegraphics[width=15cm]{modele2bis.png}


 
